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We outline the design of a framework for modelling cloud computing systems. The approach is based 
on a declarative programming model which takes the form of a A -calculus enriched with suitable 
mechanisms to express and enforce application-level security policies governing usages of resources 
available in the clouds. We will focus on the server side of cloud systems, by adopting a pro-active 
approach, where explicit security policies regulate server's behaviour. 

1 Overview 

In the old times, people used to exploit the bakery's oven for their home-made bread. Similarly, people 
utilised the public mill to obtain flour from their wheat. In both cases, people did not own the physical 
infrastructure to process their products, neither they invested on it. Instead, they rented usage from 
a third-party provider. Under this regard, the idea of cloud computing is not completely new, it just 
updates the above model and adapt it to the Internet world. Cloud Computing customers do not invest on 
hardware, software or services, but they just pay providers to use them, either on a utility or a subscription 
basis. They rely on clouds for infrastructures, platforms, and software. Cloud services and the resources 
they offer over the Internet are therefore used on demand and with a certain degree of flexibility. Thus, 
Cloud Computing is changing the fundamental way in which computing services are being delivered. 

Usually, Cloud services are based on (a farm of) servers, often virtual ones, and are fully managed 
by their providers. Consequently, old and new security problems may arise, because security is related to 
trust as more and more customers use Cloud services. Since Cloud environment is dynamically changing 
and shared by a number of users, customers expect their data or resources, when are outsourced, to be 
protected in Clouds. These expectations or requirements are usually captured in Service Level Agree- 
ment, and therefore enforcing SLAs is one of key aspects of Cloud Computing. As a result, a number of 
challenging issues comes into consideration. By going deep into it, Cloud services consist of two major 
parts: business logic and operation logic. The former models the core functionalities of the services. The 
later formalizes instead the operational tasks, i.e. the resource behavior of Cloud services. Furthermore, 
from the resource viewpoint, cloud resources come from all levels of the computing stack, hence the ef- 
fective management of the operations acting over dynamically available resources must be handled more 
carefully, possibly through strict security policies. 

Although Cloud Computing has been introduced in order to outsource IT facilities across the entire 
stack, integration is one of its important aspects. The purpose of integration is to allow customers to 
create and/or custom applications specifically suited to their unique business processes and policies. 
Hence it gives an ability to modify cloud services to match the needs of a particular goal. Again, security 
issues become more problematic under these circumstances. 
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In this paper, we advocate the usage of a declarative model based on functions with side effect to 
abstractly represent services acting over resources and service assemblies. Our main contribution is the 
formal semantics of cloud servers as functions, expressed in a suitable dialect of the A -calculus and the 
modelling of clients interactions is via asynchronous invocation. Next, we informally present the main 
features of our approach. 

Services as functions with side effects We adopt the idea of Software as a service: each service exposes 
over the network certain functional behaviour and it is invoked via request/response communication pro- 
tocols (e.g. SOAP). Services are pluggable entities and composite services are obtained by combining 
existing elementary or complex services. Following (71 [H cloud services are viewed as functions. How- 
ever, a service is not a pure function as its execution yields a side effect, thus reflecting changes of the 
service state. For instance, let us consider a simple storage service, offered by a cloud, that gets a string 
query from the user and accordingly queries the database. The following functional interface can be used 
to describe the above service. 

Table fun Q (Query q) : Effect e 

The invocation of the service Q with a query value will yield a table value as result. The side effect e 
provides the abstract representation of the modifications to the database such as updates of tables. Here, 
the side effects represent the action of accessing service resources. 

The main benefit of the service-as-function metaphor, with respect to alternative approaches based 
on process calculi (see [ 10] for a survey), is that it provides a high-level notion to model services, their 
composition and interactions, by abstracting from low level details. 

Security Policies In spite of its undeniable advantages and cost-savings, cloud computing makes data 
processing inherently risky, as data reside not under the user's control. Consequently, it is crucial that 
safety is addressed when designing a cloud. 

Our programming model focuses on application-based security by considering security policies as 
first class programming constructs. We provide explicit constructs to declare and enforce the security 
policies governing the behaviour of applications, in the style of (Hill. A security policy regulates how 
resources are granted to and used by services. For instance, let us consider the database service example 
above. The Q service may be unsafe although the code normally runs in most of the cases. An attacker 
can indeed taint the query string by injecting a command in front (SQL injection bug); consequently the 
service would issue dangerous commands such as deleting a file before executing the safe query. 

From a methodological perspective, being security-oriented from the very beginning of the develop- 
ment process facilitates the design of secure services: security is faced in advance, without sweeping it 
under the carpet (read it as security patches added later). The database service example above can be 
moved into a more secure land, by wrapping it inside a suitable security policy q>m- For instance, the 
policy can impose that no update operations on the database (i.e. system commands) can be issued during 
service executions, i.e. the only operations allowed are those in which the database content can only be 
read. Adding the specified policy to the query interface results in: 

Table fun Q (Query q) : Effect e ensuring (poB 

meaning that each step of service execution must obey the security policy <p DB . Operationally, the run- 
time structures will enforce the security policy by monitoring service execution and by catching the 
occurrences of bad actions, i.e. the actions that violate the policies. Actually, the run-time enforcement 
mechanism depends on a suitable abstraction of the execution of all the pieces of code (possibly partially) 
executed so far. This implies that the mechanism enforcing the security policies can make decisions, 
based on all previous changes of shared resources affected by different user requests. This approach, 
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known under the name of history-based security, has been receiving major attention, at both levels of 
foundations E[T2l[T3l and of language design/implementation ifTl fTTl . 

Cloud server Abstractly a cloud server can take the form of a pool of services and computational re- 
sources running over a variety of virtual machines. More precisely, a cloud server is a triple (rj \> e\ | 
e%--- || eu < o). The pair (tj, a) is the global cloud state. The r\ -component, called history, stores the 
abstract representation of the cloud behaviour. More precisely, this component exposes the evolution 
of the cloud, by detailing the occurrences of the concrete bindings among resources and services. The 
(7-component, called service store, provides a virtual representation of the service metadata supporting 
facilities to store and retrieve services. Here, a service store a is a function mapping each service name 
Pi with the metadata and scripts used to load the virtual machine and the resources required to run the 
service. Intuitively, the service name plays the role of of the service functional interface and our service 
store is a sort of service directory. Our semantic framework handles service metadata as persistent en- 
tities, i.e. they are not consumed by an invocation, but they remain in the service store. Finally, the last 
component e\ || e2 • • • || represents the expression that describes the set of services running in parallel. 
Services are functions similar to expressions in the A -calculus with a side effect acting on the global 
cloud state. Services are equipped with suitable primitives for accessing resources, for declaring and 
enforcing security policies, and for installing services and managing their invocation. For simplicity, 
we assume that resources are objects that are already available in the cloud environment (i.e. resources 
cannot be dynamically created). 

We can specify the database service discussed above as follows: 

Eform = Xq. Ep roc q where E proc = Xy. open(db); (query db y);close[db), 

where Ef orm is the cloud service acting as logical front-end with the actual database. The service gets 
a query string (q) from a user, then feeds it to E proc . In turn, the function E proc takes the query y as a 
parameter, connects to the database db, makes a query to db, by exploiting an auxiliary function query 
with the database and the query string as parameters, then closes the database connection. We abstract 
from the details of the code of the query function here, we just assume that it may perform some internal 
activities and then issues the database command dbcmd and returns a value v. 

Assume now that the configuration of the cloud server takes the form rj > link£y o ,- m || E < a. Here, 
the cloud server has activated the book-keeping service link £y om that in parallel with the execution of 
the services E performs the dynamic publication of the database service Ef orm . The constructor link£' is 
a novel construct of the calculus introduced to describe the dynamic publication of a service whose code 
is E. Operationally, the execution of the link-construct has the side effect of installing in the service store 
the service E including all the required metadata. 

In our running example, this leads to the following evolution of the cloud server: 

(tj >\wkE form \\E<a) ^ (tj -\mk>E < a[Q -)• E form ]) 

The target configuration indicates that a new service, called Q, is now available in the cloud. Furthermore, 
the history tj logs the fact that a dynamic publication has been performed. 

Client interactions are modelled explicitly: they occur via asynchronous communication in the style 
of the asynchronous TT-calculus. Intuitively, the invocation of the service % available in the service storage 
is only observed by the asynchronous occurrence of the activation of the code associated with n. For 
instance, in our running example, we have: 

/ r i\ invoken(q) . . , .. r 1x 

(tj • link D> E < o[Q -> E form \) > (tj • link • mvoke Q (g) > E form q \\E<<t[Q-> E form \). 
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This transition, that uses the new construct invoke g(<7), indicates that an instance of the service Q has 
been activated on the actual parameter q. This instance of the service runs in parallel with the other active 
services. Moreover, the service Q is still available in the cloud (i.e. services are permanent objects) and 
the history rj logs the fact that an activation of the service has been performed. 

Our treatment of service invocation has the consequent benefit to manage a variety of clients, by 
abstracting from the specific interaction protocols established with the cloud. 

Back to our running example, the database service runs as follows, where rj' stands for rj ■ link • 
invokeg (q) : 

(r\'t>E form q || E < o[Q E form ]) 
A (ri',>E proc q\\E<o[Q^E form ]) 

— > (r\\>open(db); ((query db q);close(db)) \\ E <\ o[Q — > Ef orm \) 
open(db)^ ^ open(db) > ((query db q);close(db)) \\ E< a[Q — >Ef orm ]) 
A d > A (r\' ■ open(db) ■ dbcmd D> close(db) \\ E < o[Q — > Ef orm \) 
A dose( ~ db 'i > (rj' ■ open(db) -dbcmd ■ close(db)\> E <ia[Q Ef orm \) 

As previously discussed, this behaviour is unsafe because it may contain a SQL injection bug: an 
attacker can try to inject a command in front of query string, e.g. syscmd;q', and therefore can execute 
any dangerous command such as deleting a file as as illustrated by the following trace : 



A (77' ,\>open(db); ((query db (syscmd;q'));close(db)) \\ E <\ a[Q — > Ef orm ]) 
P - — -)■ (r\' ■ open(db)\> ((query db (syscmd; q'))\close(db)) \\ E <\ o[Q — > Ef orm \) 

> (rj 1 ■ open(db) ■ syscmd > ((query db q');close(db)) \\ E <\ o[Q — > Ef orm \) 

— > >— > (rj ■ open(db) ■ syscmd ■ dbcmd \> close(db) \\ E <\ c[Q — >■ Ef orm ]) 

— > > (rj' ■ open(db) ■ syscmd ■ dbcmd ■ close(db)\> E <c[Q — ^ Ef orm \) 

To prevent this, we instrument the code Ef orm by framing it with a security policy (p D B, which does 
not allow execution of any system command. 

Following the approach of (5j|6l, a security policy is a set of traces that describe the sequences of 
events satisfying that policy. Security policies are specified via usage automata [4 ] a suitable extension 
of Finite State Automata (FSA), whose final states denote policy violations. The usage automation of 
(pus is depicted in FigfJJand the following traces show how to prevent execution of any system command: 



open db)^ ^ Q p en ^^ ^ [((query db (syscmd;q'))\close(db))] \\ E < a[Q — > Ef orm ]) 

syscmd^ 

In the full paper |5J, we introduced a notion of abstract semantics for cloud server by extending 
the notion of applicative bisimulation [2]. Intuitively, the idea behind applicative bisimulation is that in 
order to reason on the equivalence of two functions, we need to know whether their behaviors are the 
same with all possible closed values. As a consequence, applicative bisimulation relies on the output 
generated by functions, hence it does not capture the events issued by our functions The management 
of events is crucial in our framework. Service behaviour is indeed history-dependent, i.e. an expression 
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dbcmd 




syscmd 



close(db) 



Figure 1 : Usage automaton of the service Q 



may be executed differently when plugged within different cloud states. For instance, let us consider 
the cloud servers: (77 \> j3;a; <p[y] <l a) and (77 > a; j3; <p[y] < a), where 77 contains neither a nor /3, and 
the policy (p states that the sequence a;/3 is not allowed. After two transitions, the first configuration 
can make a transition that issues y, while the second cannot. We obtain a particular bisimulation (called 
cloud bisimulation) that is proved to be also a congruence and that allows us to prove that policy framings 
do not add new behaviors to the wrapped programs, i.e. behaviours of the wrapped programs are always 
simulated by their origins. Intuitively, behaviour that violates the policy is prevented to occur. In the 
running example, it appears that (Pdb[E form] ^ Ef orm . 

In summary, technical results give rise to a semantics-based methodology of safety refinement pro- 
cess in cycle of software development. Even though our present definition of bisimilarity would require 
an infinite number of checks, we are confident to circumvent this problem, by resorting to symbolic 
techniques, like the one defined in the field of software model checking. 
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